Validating map data corrections

ABSTRACT

A system for validating a correction to map data for a geographic location, the system comprising: a processing resource; and a navigation device; wherein the processing resource comprises: a user request generator that is configured to generate a user request for transmission to the navigation device; a transmitter for transmitting the generated user request to the navigation device; and a receiver for receiving a user response from said navigation device; and the navigation device comprises: a receiver for receiving the user request transmitted from the processing resource; a user request module configured to present said received user request to a user of the navigation device; a user response module for capturing a user response to said presented user request, and a transmitter for transmitting said captured user response to said processing resource.

FIELD OF THE INVENTION

The present invention relates, in general, to validating map datacorrections. Embodiments of the invention relate to a method for use inthe validation of a correction to map data for a geographic location,and to a system for use in the validation of a correction to map datafor a geographic location. Other embodiments relate to a navigationdevice and a processing resource for use in the system, and to acomputer program.

BACKGROUND TO THE INVENTION

Portable computing devices, for example Portable Navigation Devices(PNDs) that include GPS (Global Positioning System) signal reception andprocessing functionality are well known and are widely employed asin-car or other vehicle navigation systems, either as devices that arepermanently mounted in the vehicle or as devices that can be removedfrom the vehicle.

In general terms, a modern PND comprises a processor, memory (at leastone of volatile and non-volatile, and commonly both), and map datastored within said memory. The processor and memory cooperate to providean execution environment in which a software operating system may beestablished, and additionally it is commonplace for one or moreadditional software programs to be provided to enable the functionalityof the PND to be controlled, and to provide various other functions.

Typically these devices further comprise one or more input interfacesthat allow a user to interact with and control the device, and one ormore output interfaces by means of which information may be relayed tothe user. Illustrative examples of output interfaces include a visualdisplay and a speaker for audible output. Illustrative examples of inputinterfaces include one or more physical buttons to control on/offoperation or other features of the device (which buttons need notnecessarily be on the device itself but could be on a steering wheel ifthe device is built into a vehicle), and a microphone for detecting userspeech. In one particular arrangement, the output interface display maybe configured as a touch sensitive display (by means of a touchsensitive overlay or otherwise) additionally to provide an inputinterface by means of which a user can operate the device by touch.

Devices of this type will also often include one or more physicalconnector interfaces by means of which power and optionally data signalscan be transmitted to and received from the device, and optionally oneor more wireless transmitters/receivers to allow communication overcellular telecommunications and other signal and data networks, forexample Bluetooth, Wi-Fi, Wi-Max, GSM, UMTS and the like.

PNDs of this type also include a GPS antenna by means of whichsatellite-broadcast signals, including location data, can be receivedand subsequently processed to determine a current location of thedevice.

The PND may also include electronic gyroscopes and accelerometers whichproduce signals that can be processed to determine the current angularand linear acceleration, and in turn, and in conjunction with locationinformation derived from the GPS signal, velocity and relativedisplacement of the device and thus the vehicle in which it is mounted.Typically, such features are most commonly provided in in-vehiclenavigation systems, but may also be provided in PNDs if it is expedientto do so.

The utility of such PNDs is manifested primarily in their ability todetermine a route between a first location (typically a start or currentlocation) and a second location (typically a destination). Theselocations can be input by a user of the device, by any of a wide varietyof different methods, for example by postcode, street name and housenumber, previously stored “well known” destinations (such as famouslocations, municipal locations (such as sports grounds or swimmingbaths) or other points of interest), and favourite or recently visiteddestinations.

Typically, the PND is enabled by software for computing a “best” or“optimum” route between the start and destination address locations fromthe map data. A “best” or “optimum” route is determined on the basis ofpredetermined criteria and need not necessarily be the fastest orshortest route. The selection of the route along which to guide thedriver can be very sophisticated, and the selected route may take intoaccount existing, predicted and dynamically and/or wirelessly receivedtraffic and road information, historical information about road speeds,and the driver's own preferences for the factors determining road choice(for example the driver may specify that the route should not includemotorways or toll roads).

In addition, the device may continually monitor road and trafficconditions, and offer to or choose to change the route over which theremainder of the journey is to be made due to changed conditions. Realtime traffic monitoring systems, based on various technologies (e.g.mobile phone data exchanges, fixed cameras, GPS fleet tracking) arebeing used to identify traffic delays and to feed the information intonotification systems.

PNDs of this type may typically be mounted on the dashboard orwindscreen of a vehicle, but may also be formed as part of an on-boardcomputer of the vehicle radio or indeed as part of the control system ofthe vehicle itself. The navigation device may also be part of ahand-held system, such as a PDA (Portable Digital Assistant), a mediaplayer, a mobile phone or the like, and in these cases, the normalfunctionality of the hand-held system is extended by means of theinstallation of software on the device to perform both route calculationand navigation along a calculated route.

Route planning and navigation functionality may also be provided by adesktop or mobile computing resource running appropriate software. Forexample, the Royal Automobile Club (RAC) provides an on-line routeplanning and navigation facility at http://www.rac.co.uk, which facilityallows a user to enter a start point and a destination whereupon theserver with which the user's computing resource is communicatingcalculates a route (aspects of which may be user specified), generates amap, and generates a set of exhaustive navigation instructions forguiding the user from the selected start point to the selecteddestination. The facility also provides for pseudo three-dimensionalrendering of a calculated route, and route preview functionality whichsimulates a user travelling along the route and thereby provides theuser with a preview of the calculated route.

In the context of a PND, once a route has been calculated, the userinteracts with the navigation device to select the desired calculatedroute, optionally from a list of proposed routes. Optionally, the usermay intervene in, or guide the route selection process, for example byspecifying that certain routes, roads, locations or criteria are to beavoided or are mandatory for a particular journey. The route calculationaspect of the PND forms one primary function, and navigation along sucha route is another primary function.

During navigation along a calculated route, it is usual for such PNDs toprovide visual and/or audible instructions to guide the user along achosen route to the end of that route, i.e. the desired destination. Itis also usual for PNDs to display map information on-screen during thenavigation, such information regularly being updated on-screen so thatthe map information displayed is representative of the current locationof the device, and thus of the user or user's vehicle if the device isbeing used for in-vehicle navigation.

An icon displayed on-screen typically denotes the current devicelocation, and is centred with the map information of current andsurrounding roads in the vicinity of the current device location andother map features also being displayed. Additionally, navigationinformation may be displayed, optionally in a status bar above, below orto one side of the displayed map information, examples of navigationinformation include a distance to the next deviation from the currentroad required to be taken by the user, the nature of that deviationpossibly being represented by a further icon suggestive of theparticular type of deviation, for example a left or right turn. Thenavigation function also determines the content, duration and timing ofaudible instructions by means of which the user can be guided along theroute. As can be appreciated a simple instruction such as “turn left in100 m” requires significant processing and analysis. As previouslymentioned, user interaction with the device may be by a touch screen, oradditionally or alternately by steering column mounted remote control,by voice activation or by any other suitable method.

A further important function provided by the device is automatic routere-calculation in the event that: a user deviates from the previouslycalculated route during navigation (either by accident orintentionally); real-time traffic conditions dictate that an alternativeroute would be more expedient and the device is suitably enabled torecognize such conditions automatically, or if a user actively causesthe device to perform route re-calculation for any reason.

It is also known to allow a route to be calculated with user definedcriteria; for example, the user may prefer a scenic route to becalculated by the device, or may wish to avoid any roads on whichtraffic congestion is likely, expected or currently prevailing. Thedevice software would then calculate various routes and weigh morefavourably those that include along their route the highest number ofpoints of interest (known as POIs) tagged as being for example of scenicbeauty, or, using stored information indicative of prevailing trafficconditions on particular roads, order the calculated routes in terms ofa level of likely congestion or delay on account thereof. OtherPOI-based and traffic information-based route calculation and navigationcriteria are also possible.

Although the route calculation and navigation functions are fundamentalto the overall utility of PNDs, it is possible to use the device purelyfor information display, or “free-driving”, in which only mapinformation relevant to the current device location is displayed, and inwhich no route has been calculated and no navigation is currently beingperformed by the device. Such a mode of operation is often applicablewhen the user already knows the route along which it is desired totravel and does not require navigation assistance.

Devices of the type described above, for example the 920T modelmanufactured and supplied by TomTom International B.V., provide areliable means for enabling users to navigate from one position toanother. Such devices are of great utility when the user is not familiarwith the route to the destination to which they are navigating.

As mentioned above, the memory of the PND stores map data used by thePND not only to calculate routes and provide necessary navigationinstructions to users, but also to provide visual information to usersthrough the visual display of the PND. As is known in the art, mapinformation can be expressed in a number of ways and indeed can comprisea number of separate information components, which are used incombination by the PND.

Map databases often provide details of road networks for an entirecountry or even an entire continent, and as such they typically includea vast amount of information. The real road network that is embodied inthe map database changes over time, and whilst it is conventional formap providers to provide updates for application to map databases, therate of change inevitably means that even the most up to date databasesinclude errors that require correction. For example, new roads may bebuilt after a given map has been created, or existing routes may betemporarily or permanently diverted. Furthermore, as the type ofinformation included in these map databases increases, for example toinclude information regarding points of interest (such as theme parks,museums, banks or filling stations), so the problem of map data accuracyis compounded as new points of interest appear and old points ofinterest disappear.

Conventionally the accuracy of map data is checked by sending outindividuals, typically employees of the map provider, to follow the mapand note any inconsistencies or errors they encounter. In some instancesusers may be provided with the opportunity to participate in the processof map verification by logging errors in the map data that theyencounter as they use their devices.

Map Share™, provided by TomTom™, is an illustrative example of suchfunctionality. Users of certain TomTom™ navigation devices can use theMap Share™ functionality to share corrections that they make to the mapdata stored in their devices with other TomTom™ users who have agreed tobe part of the Map Share™ community. Users can choose to receive MapShare™ map data corrections, and can assign a level of trust to indicatewhether they are happy to include all received corrections in their mapdata, or whether they only wish to include officially sanctioned andverified Map Share™ corrections.

Whilst the functionality provided by Map Share™ does help to reduce theincidence of errors in the map data held by those users who sign up tothe service, there is a still a degree of verification that needs to beundertaken before officially verified corrections can be released to allusers as a map data update from the map provider. This verificationprocess necessarily takes time to complete, and as such if a user wishesto have the most up to date map data available they necessarily need tochoose to include map data that has not yet been officially verified.

Whilst most users of functionality such as Map Share™ are seeking toimprove the accuracy of the map data for all users, there isunfortunately a significant minority of device users who deliberatelyseek to introduce errors into the map data by reporting “corrections”that they know to be false. Those users of the Map Share functionalitywho have opted to trust all corrections submitted by the community canfind that these deliberately false “corrections” get imported into theirmap data, and can be inconvenienced if they should rely on those“corrections” when planning a route.

One solution to this problem would be for the map provider to validateall user submitted corrections before releasing a map update to users,but as aforementioned validation processes are in the first instancerelatively expensive to undertake and in the second instance necessarilytake time to complete, and whilst such processes are being completedusers have no option but to rely on incorrect map data.

It is clear, therefore, that it would be an advantage if processeswhereby users can provide information concerning the accuracy of mapdata can be improved to simultaneously reduce the requirement forvalidation by the map provider and the likelihood of the map data beingaffected by false map corrections. One illustrative aim of the presentinvention is to provide such an arrangement.

SUMMARY OF THE INVENTION

In pursuit of this aim, a first aspect of the present invention providesa system for use in the validation of a correction to map data for ageographic location, the system comprising: a processing resource; and anavigation device; wherein the processing resource comprises: a userrequest generator that is configured to generate a user request fortransmission to the navigation device; a transmitter for transmittingthe generated user request to the navigation device; and a receiver forreceiving a user response from said navigation device; and thenavigation device comprises: a receiver for receiving the user requesttransmitted from the processing resource; a user request moduleconfigured to present said received user request to a user of thenavigation device; a user response module for capturing a user responseto said presented user request, and a transmitter for transmitting saidcaptured user response to said processing resource.

In one envisaged implementation, the user request includes positioninformation defining one or more geographic locations at which said userrequest module presents said user request to said user.

The navigation device may include a navigation module configured todetermine the geographic position of the navigation device, and saiduser request module may configured to present said user request to theuser when said navigation module indicates that the geographic locationof said navigation device is included in said position information.

In an illustrative implementation, the position information defines azone that is a predetermined distance from the location associated withsaid geographic location. In another implementation, the predetermineddistance may vary in accordance with the type of correction that is tobe validated.

The user request generator may be configured to generate a plurality ofuser requests, each for transmission to a different navigation device.

The processing resource may comprise a device selection module operableto select navigation devices to which generated user requests are to betransmitted.

The processing resource may comprise a route log configured to storenavigation routes travelled by navigation devices.

The device selection module may be configured to select a set of devicesfor which a route is stored in said route log that includes a locationin the vicinity of the geographic location associated with saidcorrection.

The device selection module may be configured to select a set of devicesfor which a route is stored in said route log that includes thegeographic location associated with said correction.

In a preferred arrangement, the device selection module may beconfigured to randomly select a set of devices from a plurality ofdevices for each of which a route is stored in said route log thatincludes a location in the vicinity of the geographic locationassociated with said correction.

The processing resource comprises a response review module for analysinguser responses to validate said correction.

The user request module may be configured to present said user requestby playing an audio message to said user. The user request module may,alternatively or additionally, be configured to present said userrequest by displaying a visual message to said user.

A second aspect of the present invention relates to a method for use inthe validation of a correction to map data for a geographic location,the method comprising: generating a user request for transmission from aprocessing resource to a navigation device, transmitting the generateduser request to the navigation device; controlling the navigation deviceto present the user request to a user of the navigation device;capturing a user response to said presented user request; andtransmitting the user response to said processing resource.

The method may further comprise analysing said user response to validatesaid correction.

A third aspect of the present invention provides a method for use in thevalidation of a correction to map data for a geographic location, themethod comprising: generating a user request for transmission from aprocessing resource to a navigation device; transmitting the generateduser request to the navigation device for presentation of the userrequest to a user of the navigation device; and receiving from anavigation device a user response to a presented user request.

A fourth aspect of the present invention provides a method for use inthe validation of a correction to map data for a geographic location,the method comprising: receiving, at a navigation device, a user requesttransmitted from a processing resource; controlling the navigationdevice to present the user request to a user of the device; capturing auser response to said presented request; and transmitting said userresponse to said processing resource.

A fifth aspect of the present invention provides a computer programcomprising one or more computer program modules configured, whenexecuted by a processor resource, to cause the processor resource toimplement a method as defined herein. A sixth aspect of the presentinvention relates to a computer program as described herein, embodied atleast in part on a computer readable medium.

A seventh aspect of the present invention provides a processing resourceconfigured for use in a system for use in the validation of a correctionto map data for a geographic location, the system comprising anavigation device that includes a receiver for receiving user requeststransmitted from the processing resource, a user request moduleconfigured to present a received user request to a user of thenavigation device; a user response module for capturing a user responseto said presented user request, and a transmitter for transmitting saidcaptured user response to said processing resource; the processingresource comprising: a user request generator that is configured togenerate a user request for transmission to the navigation device; atransmitter for transmitting the generated user request to thenavigation device; and a receiver for receiving the user response fromsaid navigation device.

An eighth aspect of the present invention relates to a navigation deviceconfigured for use in a system for use in the validation of a correctionto map data for a geographic location, the system comprising aprocessing resource that includes a user request generator that isconfigured to generate a user request for transmission to the navigationdevice; a transmitter for transmitting the generated user request to thenavigation device; and a receiver for receiving from said navigationdevice a user response to a user request presented to a user of saidnavigation device; the navigation device comprising: a receiver forreceiving the user request transmitted from the processing resource; auser request module configured to present said received user request toa user of the navigation device; a user response module for capturingthe user response to said presented user request, and a transmitter fortransmitting said captured user response to said processing resource.

A nine aspect of the present invention relates to a method for use inthe validation of a correction to map data for a geographic location,the method comprising generating a request that solicits a navigationdevice user response, transmitting said request to a plurality ofdevices, displaying said request to a plurality of navigation deviceusers, and receiving user responses to said displayed requests.

Advantages of these embodiments are set out hereafter, and furtherdetails and features of each of these embodiments are defined in theaccompanying dependent claims and elsewhere in the following detaileddescription.

It is thus possible to provide a powerful means for validating requestedcorrections to map data in a navigation system. The arrangementsdisclosed avoid much of the expense associated with traditional methodsof validating correction requests, and facilitate a quicker respond tonoted errors. Furthermore, in preferred embodiments of the invention itis significantly harder for nefarious individuals to pollute the mapdata with incorrect submissions.

BRIEF DESCRIPTION OF THE DRAWINGS

Illustrative embodiments of the invention will now be described, by wayof example only, with reference to the accompanying drawings, in which:

FIG. 1 is a schematic illustration of an illustrative part of a GlobalPositioning System (GPS) usable by a navigation device;

FIG. 2 is a schematic diagram of a communications system that may beemployed to provide for communication between a navigation device and aserver;

FIG. 3 is a schematic illustration of electronic components of anillustrative navigation device, for example the device of FIG. 2;

FIG. 4 is a schematic diagram of an arrangement for mounting and/ordocking a navigation device;

FIG. 5 is a schematic representation of an architectural stack employedby the navigation device of FIG. 3;

FIG. 6 is a more detailed view of the arrangement shown in FIG. 2;

FIGS. 7 to 18 are screenshots of an illustrative map data errorreporting process;

FIGS. 19 and 20 are screenshots of an illustrative location markingprocess;

FIG. 21 is a more detailed schematic representation of an architecturalstack employed by the server of FIG. 6;

FIGS. 22 and 23 are screenshots depicting an illustrative user requestdisplayed on a navigation device;

FIG. 24 is a more detailed schematic representation of an architecturalstack employed by the navigation device of FIG. 6; and

FIGS. 25 and 26 provide an overview in flow chart form of anillustrative embodiment of the invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Throughout the following description identical reference numerals willbe used to identify like parts.

Embodiments of the present invention will now be described withparticular reference to a PND. It should be remembered, however, thatthe teachings of the present invention are not limited to PNDs but areinstead universally applicable to any type of processing device that isconfigured to execute navigation software so as to provide routeplanning and/or navigation functionality. It follows therefore that inthe context of the present application, a navigation device is intendedto include (without limitation) any type of route planning andnavigation device, irrespective of whether that device comprises a PND,a device in a vehicle such as an automobile, or indeed a computingresource, for example a personal computer (PC) (portable or otherwise),a mobile telephone or a Personal Digital Assistant (PDA) executing routeplanning and navigation software.

It will also be apparent from the following that the teachings of thepresent invention are not limited solely to circumstances where usersare following a computed route from an input start location to an inputdestination location, but are equally as useful when the user is usingthe device in the aforementioned free-driving mode.

With the above provisos in mind, reference will now be made to FIG. 1 ofthe accompanying drawings in which an illustrative satellite navigationsystem, in this instance, the Global Positioning System (GPS) is shown.In general, the GPS is a satellite-radio based navigation system thatprovides the possibility of continuously determining position, velocity,time, and in some instances direction information for an unlimitednumber of users. Formerly known as NAVSTAR, the GPS incorporates aplurality of satellites which orbit the earth in extremely preciseorbits. Based on these precise orbits, GPS satellites can relay theirlocation to any number of receiving units.

The GPS system is implemented when a device, specially equipped toreceive GPS data, begins scanning radio frequencies for GPS satellitesignals. Upon receiving a radio signal from a GPS satellite, the devicedetermines the precise location of that satellite via one of a pluralityof different conventional methods. The device will continue scanning, inmost instances, for signals until it has acquired at least threedifferent satellite signals (noting that position is not normally, butcan be determined, with only two signals using other triangulationtechniques). Implementing known geometric triangulation techniques, thereceiver utilizes the three known positions to determine its owntwo-dimensional position relative to the satellites. Additionally, byacquiring a fourth satellite signal the receiving device can calculateits three dimensional position by the same geometrical calculation in aknown manner. The position and velocity data can be updated in real timeon a continuous basis by an unlimited number of users.

As shown in FIG. 1, the GPS system 100 comprises a plurality ofsatellites 102 orbiting about the earth 104. A GPS receiver 106 receivesspread spectrum GPS satellite data signals 108 from a number of theplurality of satellites 102. The spread spectrum data signals 108 arecontinuously transmitted from each satellite 102, the spread spectrumdata signals 108 transmitted each comprise a data stream includinginformation identifying a particular satellite 102 from which the datastream originates. The GPS receiver 106 generally requires spreadspectrum data signals 108 from at least three satellites 102 in order tobe able to calculate a two-dimensional position. Receipt of a fourthspread spectrum data signal enables the GPS receiver 106 to calculate,using a known technique, a three-dimensional position.

Turning to FIG. 2, a navigation device 200 comprising or coupled to theGPS receiver device 106, is capable of establishing a data session, ifrequired, with network hardware of a “mobile” or telecommunicationsnetwork via a mobile device (not shown), for example a mobile telephone,PDA, and/or any device with mobile telephony or communicationsfunctionality, in order to establish a digital connection, for example adigital connection via known Bluetooth technology. Thereafter, throughits network service provider, the mobile device can establish a networkconnection (through the Internet for example) with a server 150. Assuch, a “mobile” network connection can be established between thenavigation device 200 (which can be, and often times is, mobile as ittravels alone and/or in a vehicle) and the server 150 to provide a“real-time” or at least very “up to date” gateway for information.

The establishing of the network connection between the mobile device(via a service provider) and another device such as the server 150,using the Internet for example, can be done in a known manner. In thisrespect, any number of appropriate data communications protocols can beemployed, for example the TCP/IP layered protocol. Furthermore, themobile device can utilize any number of communication standards such asCDMA2000, GSM, IEEE 802.11 a/b/c/g/n, etc.

Hence, it can be seen that the internet connection may be utilised,which can be achieved via data connection, via a mobile phone or mobilephone technology within the navigation device 200 for example.

Although not shown, the navigation device 200 may, of course, includeits own mobile telephone technology within the navigation device 200itself (including an antenna for example, or optionally using theinternal antenna of the navigation device 200). The mobile phonetechnology within the navigation device 200 can include internalcomponents, and/or can include an insertable card (e.g. SubscriberIdentity Module (SIM) card), complete with necessary mobile phonetechnology and/or an antenna for example. As such, mobile phonetechnology within the navigation device 200 can similarly establish anetwork connection between the navigation device 200 and the server 150,via the Internet for example, in a manner similar to that of any mobiledevice.

For telephone settings, a Bluetooth enabled navigation device may beused to work correctly with the ever changing spectrum of mobile phonemodels, manufacturers, etc., model/manufacturer specific settings may bestored on the navigation device 200 for example. The data stored forthis information can be updated.

In FIG. 2, the navigation device 200 is depicted as being incommunication with the server 150 via a generic communications channel152 that can be implemented by any of a number of differentarrangements. The communication channel 152 generically represents thepropagating medium or path that connects the navigation device 200 andthe server 150. The server 150 and the navigation device 200 cancommunicate when a connection via the communications channel 152 isestablished between the server 150 and the navigation device 200 (notingthat such a connection can be a data connection via mobile device, adirect connection via personal computer via the internet, etc.).

The communication channel 152 is not limited to a particularcommunication technology. Additionally, the communication channel 152 isnot limited to a single communication technology; that is, the channel152 may include several communication links that use a variety oftechnology. For example, the communication channel 152 can be adapted toprovide a path for electrical, optical, and/or electromagneticcommunications, etc. As such, the communication channel 152 includes,but is not limited to, one or a combination of the following: electriccircuits, electrical conductors such as wires and coaxial cables, fibreoptic cables, converters, radio-frequency (RF) waves, the atmosphere,free space, etc. Furthermore, the communication channel 152 can includeintermediate devices such as routers, repeaters, buffers, transmitters,and receivers, for example.

In one illustrative arrangement, the communication channel 152 includestelephone and computer networks. Furthermore, the communication channel152 may be capable of accommodating wireless communication, for example,infrared communications, radio frequency communications, such asmicrowave frequency communications, etc. Additionally, the communicationchannel 152 can accommodate satellite communication.

The communication signals transmitted through the communication channel152 include, but are not limited to, signals as may be required ordesired for given communication technology. For example, the signals maybe adapted to be used in cellular communication technology such as TimeDivision Multiple Access (TDMA), Frequency Division Multiple Access(FDMA), Code Division Multiple Access (CDMA), Global System for MobileCommunications (GSM), etc. Both digital and analogue signals can betransmitted through the communication channel 152. These signals may bemodulated, encrypted and/or compressed signals as may be desirable forthe communication technology.

The server 150 includes, in addition to other components which may notbe illustrated, a processor 154 operatively connected to a memory 156and further operatively connected, via a wired or wireless connection158, to a mass data storage device 160. The mass storage device 160contains a store of navigation data and map information, and can againbe a separate device from the server 150 or can be incorporated into theserver 150. The processor 154 is further operatively connected totransmitter 162 and receiver 164, to transmit and receive information toand from navigation device 200 via communications channel 152. Thesignals sent and received may include data, communication, and/or otherpropagated signals. The transmitter 162 and receiver 164 may be selectedor designed according to the communications requirement andcommunication technology used in the communication design for thenavigation system 200. Further, it should be noted that the functions oftransmitter 162 and receiver 164 may be combined into a singletransceiver.

As mentioned above, the navigation device 200 can be arranged tocommunicate with the server 150 through communications channel 152,using transmitter 166 and receiver 168 to send and receive signalsand/or data through the communications channel 152, noting that thesedevices can further be used to communicate with devices other thanserver 150. Further, the transmitter 166 and receiver 168 are selectedor designed according to communication requirements and communicationtechnology used in the communication design for the navigation device200 and the functions of the transmitter 166 and receiver 168 may becombined into a single transceiver as described above in relation toFIG. 2.

The navigation device includes a data storage device 170 (which maycomprise any combination of ROM, RAM and disk based or solid statestorage device) as well as other hardware and/or functional parts, whichwill be described later herein in further detail.

Software stored in server memory 156 provides instructions for theprocessor 154 and allows the server 150 to provide services to thenavigation device 200. In one configuration a service provided by theserver 150 may involve processing requests from the navigation device200 and transmitting navigation data from the mass data storage 160 tothe navigation device 200. Another service that can be provided by theserver 150 includes processing the navigation data using variousalgorithms for a desired application and sending the results of thesecalculations to the navigation device 200.

The server 150 constitutes a remote source of data accessible by thenavigation device 200 via a wireless channel. The server 150 may includea network server located on a local area network (LAN), wide areanetwork (WAN), virtual private network (VPN), etc.

The server 150 may include a personal computer such as a desktop orlaptop computer, and the communication channel 152 may be a cableconnected between the personal computer and the navigation device 200.Alternatively, a personal computer may be connected between thenavigation device 200 and the server 150 to establish an internetconnection between the server 150 and the navigation device 200.

In general terms the server comprises a processing resource, comprisingany number and type of processing devices (linked together or separate),remote from the navigation device 200 and with which the navigationdevice can communicate by means or a wired or wireless communicationschannel.

The navigation device 200 may be provided with information from theserver 150 via information downloads which may be periodically updatedautomatically or upon a user connecting the navigation device 200 to theserver 150 and/or may be more dynamic upon a more constant or frequentconnection being made between the server 150 and navigation device 200via a wireless mobile connection device and TCP/IP connection forexample. For many dynamic calculations, the processor 154 in the server150 may be used to handle the bulk of processing needs, however, aprocessor (not shown in FIG. 2) of the navigation device 200 can alsohandle much processing and calculation, oftentimes independent of aconnection to a server 150.

Referring to FIG. 3, it should be noted that the block diagram of thenavigation device 200 is not inclusive of all components of thenavigation device, but is only representative of many examplecomponents. The navigation device 200 is located within a housing (notshown). The navigation device 200 includes a processing resourcecomprising, for example, the processor 202 mentioned above, theprocessor 202 being coupled to an input device 204 and a display device,for example a display screen 206. Although reference is made here to theinput device 204 in the singular, the skilled person should appreciatethat the input device 204 represents any number of input devices,including a keyboard device, voice input device, touch panel and/or anyother known input device utilised to input information. Likewise, thedisplay screen 206 can include any type of display screen such as aLiquid Crystal Display (LCD), for example.

In one arrangement, one aspect of the input device 204, the touch panel,and the display screen 206 are integrated so as to provide an integratedinput and display device, including a touchpad or touchscreen input 250(FIG. 4) to enable both input of information (via direct input, menuselection, etc.) and display of information through the touch panelscreen so that a user need only touch a portion of the display screen206 to select one of a plurality of display choices or to activate oneof a plurality of virtual or “soft” buttons. In this respect, theprocessor 202 supports a Graphical User Interface (GUI) that operates inconjunction with the touchscreen.

In the navigation device 200, the processor 202 is operatively connectedto and capable of receiving input information from input device 204 viaa connection 210, and operatively connected to at least one of thedisplay screen 206 and the output device 208, via respective outputconnections 212, to output information thereto. The navigation device200 may include an output device 208, for example an audible outputdevice (e.g. a loudspeaker). As the output device 208 can produceaudible information for a user of the navigation device 200, it isshould equally be understood that input device 204 can include amicrophone and software for receiving input voice commands as well.Further, the navigation device 200 can also include any additional inputdevice 204 and/or any additional output device, such as audioinput/output devices for example.

The processor 202 is operatively connected to memory 214 (which maycomprise any combination of ROM, RAM, disk drive or solid state storagedevices, and may be part of the aforementioned data storage device 170)via connection 216 and is further adapted to receive/send informationfrom/to input/output (I/O) ports 218 via connection 220, wherein the I/Oport 218 is connectible to an I/O device 222 external to the navigationdevice 200. The external I/O device 222 may include, but is not limitedto an external listening device, such as an earpiece for example. Theconnection to I/O device 222 can further be a wired or wirelessconnection to any other external device such as a car stereo unit forhands-free operation and/or for voice activated operation for example,for connection to an earpiece or headphones, and/or for connection to amobile telephone for example, wherein the mobile telephone connectioncan be used to establish a data connection between the navigation device200 and the Internet or any other network for example, and/or toestablish a connection to a server via the Internet or some othernetwork for example.

FIG. 3 further illustrates an operative connection between the processor202 and an antenna/receiver 224 via connection 226, wherein theantenna/receiver 224 can be a GPS antenna/receiver for example. Itshould be understood that the antenna and receiver designated byreference numeral 224 are combined schematically for illustration, butthat the antenna and receiver may be separately located components, andthat the antenna may be a GPS patch antenna or helical antenna forexample.

It will, of course, be understood by one of ordinary skill in the artthat the electronic components shown in FIG. 3 are powered by one ormore power sources (not shown) in a conventional manner. As will beunderstood by one of ordinary skill in the art, different configurationsof the components shown in FIG. 3 are contemplated. For example, thecomponents shown in FIG. 3 may be in communication with one another viawired and/or wireless connections and the like. Thus, the navigationdevice 200 described herein can be a portable or handheld navigationdevice 200.

In addition, the portable or handheld navigation device 200 of FIG. 3can be connected or “docked” in a known manner to a vehicle such as abicycle, a motorbike, a car or a boat for example. Such a navigationdevice 200 is then removable from the docked location for portable orhandheld navigation use.

Referring to FIG. 4, the navigation device 200 may be a unit thatincludes the integrated input and display device 206 and the othercomponents of FIG. 2 (including, but not limited to, the internal GPSreceiver 224, the microprocessor 202, a power supply (not shown), memorysystems 214, etc.).

The navigation device 200 may sit on an arm 252, which itself may besecured to a vehicle dashboard/window/etc. using a suction cup 254. Thisarm 252 is one example of a docking station to which the navigationdevice 200 can be docked. The navigation device 200 can be docked orotherwise connected to the arm 252 of the docking station by snapconnecting the navigation device 200 to the arm 252 for example. Thenavigation device 200 may then be rotatable on the arm 252. To releasethe connection between the navigation device 200 and the dockingstation, a button (not shown) on the navigation device 200 may bepressed, for example. Other equally suitable arrangements for couplingand decoupling the navigation device 200 to a docking station are wellknown to persons of ordinary skill in the art.

Referring to FIG. 5, the processor 202 and memory 214 of the navigationdevice cooperate to support a BIOS (Basic Input/Output System) 282 thatfunctions as an interface between functional hardware components 280 ofthe navigation device 200 and software executed by the device. Theprocessor 202 is configured to load an operating system 284 from thememory 214, and the operating system provides a processing environmentin which application software 286 (implementing some or all of the routeplanning, navigation and other functionality described herein) can run.The application software 286 provides an operational environmentincluding a GUI that supports core functions of the navigation device,for example map viewing, route planning, navigation functions and otherfunctions associated therewith.

Details of preferred embodiments of the present invention will now bedescribed with particular reference to a system, such as Map Share™,whereby users can choose to provide feedback to the map provider (whomay or may not be the same entity from whom users source navigationdevices) concerning corrections that might be appropriate forapplication to the digital map data held by the map provider. Whilst thefollowing detailed description will make particular reference to MapShare™ it will be appreciated that the present invention is applicableto any user feedback system for navigation map data, and as such thescope of the present invention should not be interpreted as beinglimited solely for application to the TomTom Map Share™ system.

Referring now to FIG. 6, in a preferred embodiment of the presentinvention the mass data storage 160 of the server 150 is configured toinclude a map data store 300, a correction log 302 and a route log 304.Similarly, data storage 170 of the navigation device 200 includes a mapdata store 306, a user correction log 308 and a route log 310. Althoughnot shown in FIG. 6, the server 150 also maintains a log of those userdevices that have opted in to the user feedback system.

The map data stores 300, 306 include digital map data that is used bynavigation devices, in a known manner, to provide users with the abilityto navigate between locations in the map and to provide rendered mapsfor display to users. The server-side correction log 302 includesdetails of map correction requests submitted by users for incorporationinto the digital map defined by the digital data held in the map datastore 300 if it is appropriate to do so, and the server-side route log304 includes data concerning the routes travelled by navigation deviceusers who have subscribed to the navigation data improvement system.Typically the server-side route log 304 includes, for each route store,data defining the route travelled as well as an identifier that uniquelyidentifies the navigation device used whilst that route was beingtravelled.

The user correction log 308 comprises a database of instances where theuser has indicated that a map data correction is required and the typeof correction that the user believes should be made. As will beappreciated by persons skilled in the art, such a list can be compiledin a number of different ways, one of which will later be described.Depending on the type of connection between the navigation device 200and server 150, data from the user correction log 308 can be transferredto the server 150 whilst the navigation device is still mobile, or in aparticularly preferred implementation the log can be transferred to theserver when the navigation device is next connected to the server forupdating.

The route log 310 comprises a database of routes travelled by the user'snavigation device 200; typically only the routes travelled since thelast time the navigation device was connected to the server. Thedatabase includes details of those routes where the device was operatedto guide the user to a selected destination, and may also includedetails of routes travelled whist in free-driving mode.

In the course of a data communications session with the server 150, mapdata updates (if any are available) are provided from the server-sidemap data store 300 to the navigation device 200 for storage in thenavigation device map data store 306, and data from the user correctionlog 308 and route log 310 (if any is stored) is transferred from thenavigation device 200 to the server 150 for storage in the correctionlog 302 and route log, respectively.

Referring now to FIGS. 7 to 18, there are shown various screenshots froma TomTom™ Go 720 navigation device which illustrate one way in which auser of a navigation device can log a correction that they believe needsto be made to the navigation data, in this instance the navigation datastored in their device

In FIG. 7, the device is displaying a map of the area of Londonsurrounding Bouverie Street. Touching the screen of the device causes itto display a number of options, as shown in FIG. 8, and a continuationarrow 312. Touching the continuation arrow 312 causes the device todisplay, as shown in FIG. 9, another series of options that include avirtual button 314 labelled “map corrections”.

Touching the “map corrections” button 314 causes the device to displaythe map corrections options shown in FIG. 10, which options include avirtual button 316 labelled “correct a map error”. Touching this button316 causes the device to display, as shown in FIG. 11, a number ofvirtual buttons that each correspond to a different type of mapcorrection. In total the TomTom Go 720 provides seven predefined typesof correction (only five of which are shown in FIG. 11) and a “reportother error” which allows users to select types of error other than theseven predefined error types.

In this instance we imagine that the user wishes to correct a speedlimit that is associated with a road of the digital map, and toimplement this the user touches a virtual button 318 labelled “changeroad speed”, whereupon the device displays four different options, asshown in FIG. 11, for locating the road in question.

Let us assume in this example that the incorrect speed limit isassociated with the road in the vicinity of the device's currentlocation, namely Bouverie Street, London. Touching a virtual button 320labelled “near you” causes the device to display a map of the local areaas shown in FIG. 12. The user can then select the street in the localarea (in this example: Fleet Street) that requires correction of thespeed limit associated with it by touching the screen and once selected,as shown in FIG. 13, at least part of the chosen road is highlighted andthe name of the road is displayed.

The user is then asked to confirm, as shown in FIG. 14, whether thehighlighted part of the road is the part that the user intended toselect, and on touching the virtual button 322 labelled “Yes” the devicegenerates the display indicated in FIG. 15 and the user is asked toenter the correct speed limit for the section of road selected in FIG.14. In this instance the user has indicated that the correct speed limitfor this section of road is 30 miles per hour.

When the user has input the correct speed limit, selecting virtualbutton 324 labelled “done” causes the device to generate a display asshown in FIG. 16 which requests the user to confirm that the change is“permanent and valid for normal passenger cars” (we assume it is in thisexample), following which the user is advised by way of the displayshown in FIG. 17 that their map has been changed and is prompted toindicate by touching the appropriate virtual button whether they wish toshare this change with other TomTom users. If the user touches thevirtual button 326 marked “yes” the location of the correction, thenature of the correction and, in this case, the new data associated withthat location are stored in the user correction log 308 for download tothe correction log 302 of the server 150 when the device is next incommunication with the server, and the user is advised accordingly asshown in FIG. 18.

As will be appreciated, this process is quite involved and as such maybe involved to be undertaken whilst the device is being used,particularly if the device is being used for navigation in a vehicle. Toaccommodate this, the software provides the user with the option tooverlay the displayed navigation map, as shown in FIG. 19, with avirtual “report” button 324, and if the user should press this buttonthe device provides a display as shown in FIG. 20 to indicate to theuser that the location where the report button was pressed has beenlogged so that the process depicted in FIGS. 7 to 18 can be undertakenat a more convenient time when the user next presses the “mapcorrections” button 314 shown in FIG. 9.

As aforementioned the server processor is configured to invoke andexecute software modules in server memory 156. In particular, as shownin FIG. 21, the processor 154 and memory 156 cooperate to support a BIOS(Basic Input/Output System) 330 that functions as an interface betweenfunctional hardware components of the server 150 and software executedby the server 150. The processor 154 is configured to load an operatingsystem 332, for example from the memory 156, for execution in theprocessing environment provided by the memory 156. The operating system332 provides a processing environment in which application software 334can run.

In a preferred embodiment of the present invention the serverapplication software 334 comprises a correction selection module 336, adevice selection module 338, a user request generator 340, a responsereview module 342 and a correction application module 344.

The correction selection module 336 is configured to select notifiedcorrections and associated locations from the correction log 302 forvalidation by navigation device users. The module may select notifiedcorrections in turn (starting with the oldest notified errors first), atrandom, or once multiple users (for example, more users than apredetermined minimum number of users) have reported a particularproblem.

In one envisaged arrangement the server may be configured to implement acorrection log maintenance module (not shown in FIG. 21) that isconfigured to review the correction log and exclude from considerationfor user validation those corrections that have been requested by only asmall number of users or on a small number of occasions. Thesecorrections are likely to be relatively minor in nature or to relate torelative obscure locations that are unlikely to be visited by manyusers, and as such may be more appropriate for validation by anemployee, for example, than by means of a user validation process of thetype described herein.

The device selection module 338 is configured to inspect the route log304 and, in one configuration, select devices that have previouslytravelled routes which include the particular location associated withthe correction selected for validation from the correction log 302 bythe correction selection module 336.

The device selection process can take a number of different forms. Inone configuration, the device selection module 338 may be configured toselect the first X devices from the route log that have travelled aroute which includes the location associated with the selectedcorrection (where X is a number chosen as the minimum number of userdevices that must be selected for a requested correction). In aparticularly preferred arrangement the number X may be a function of thenumber of devices with routes that pass the location. In other words,the number X may be, preferably automatically, dynamically adjustedupwards for locations that have been visited by many devices anddownwards for locations that have been visited by a smaller number ofdevices.

In another arrangement the device selection module 338 may be configuredto identify a set of devices which have travelled a route that includesthe location associated with the selected correction, and then randomlyselect from this set a subset of X devices (where, as before, X is anumber chosen (optionally dynamically) for the system) that are to becontacted for correction validation purposes. This random selection isparticularly preferred as it makes it less likely that a chosen devicewill be associated with a false correction that has been deliberatelysubmitted to adversely affect the integrity of the map data.

In another arrangement, the device selection module 338 may beconfigured to identify a set of devices which have travelled a routethat includes the location associated with the selected correction, rankthe set of devices (for example by the number of times that the deviceconcerned has travelled through the selected location), and then selecta subset of X devices (where, as before, X is a number chosen(optionally dynamically) for the system) consisting of the devices thathave most frequently visited the location and which are to be contactedfor correction validation purposes. As before, the devices selected forinclusion in this subset may be chosen at random from a subsetconsisting of those devices that have most frequently visited thelocation in question.

In another envisaged implementation, the device selection module may beconfigured to select for consideration not only those devices that haveactually passed through the location in question, but also those devicesthat have been in the vicinity of the location in question, for examplewithin a kilometre or less of the location in question. In aparticularly preferred arrangement, the device selection module may beconfigured to dynamically adjust the definition of the “vicinity” for agiven location in accordance with the number of routes in the log thatactually include the particular location associated with the requestedcorrection. For example, for a correction associated with a particularlocation that has been visited on many occasions in the past, the deviceselection module may adjust the definition of the “vicinity” of thatlocation downwards, perhaps to include only those devices for whomroutes are recorded that actually include the location in question.Conversely, for a correction associated with a particular location thathas been visited on a relatively small number of occasions in the past,the device selection module may adjust the definition of the “vicinity”of that location upwards, perhaps to include those devices for whomroutes are recorded that include locations within a given distance (forexample a kilometre) of the location associated with the requestedcorrection.

The user request generator 340 is configured to generate, for theparticular correction type included in the correction log 302, userrequests that each comprise a set of instructions for transfer to eachof the navigation devices selected by the device selection module 338.The instructions, when executed by the respective processors 202 of thenavigation devices 200 will cause those devices to generate and presentto the user of the device a request for user assistance in thevalidation of a reported map data correction. The user requests, oncegenerated, are stored by the server (for example in the mass datastorage 160) for transfer to the navigation devices associated with eachgenerated request on the next occasion that the device communicates withthe server 150.

In the preferred embodiment the user request instructions identify tothe processors of the navigation devices a location (which may comprisea single location or a zone comprising a plurality of locations apredetermined distance from a location with which the requestedcorrection is associated) with which the user requests are associated,and the processors of the navigation devices are configured to executethe instructions of the user requests only when a position determinationmodule (to be later described) of each navigation device indicates thatthe navigation device is at or near the location in question. In aparticularly preferred arrangement the instructions may be configured tocontrol the processor to present the request to the user at a locationwhich is a predetermined distance before the location associated withthe requested correction, and in a modification of this arrangement thepredetermined distance may be varied in accordance with the type ofcorrection with which the user is being asked to assist. For example,for a correction relating to a street name, the user may be presentedwith the request shortly before they enter the street in question (onthe rationale that street signs are usually provided at entrances to astreet). Alternatively, for a correction relating to speed limitsassociated with a given street, the user may be presented with therequest only once they are actually in the street in question (on therationale that speed limit signs are usually provided at regularintervals along a street).

In another contemplated implementation that is particularly suitable foruse with those locations that are typically visited less often, the userrequest instructions could be configured to instruct the processor todivert the user from their chosen or current route to the locationassociated with the correction. For example, a user could be presentedwith a message asking for assistance with a correction that isassociated with a minor street that is not far away from a street alongwhich they are proceeding, and if the user should indicate that they areprepared to assist with the request, the processor could vary theplanned route to include the street in question or in the case where theuser is using the device in a free driving mode, issue the user withinstructions to guide the user from their current position to thelocation in question, and optionally back to the location they were atbefore they were diverted.

The user requests provided to the user may take a number of forms. Theymay comprise visually displayed requests for assistance, audio requestsfor assistance or, in a particularly preferred arrangement, combinationsof audio and visual requests for assistance.

FIG. 22 is an illustrative representation for a user feedback requestconcerning a reporting correction to the name of a particular street. Asshown, in this arrangement the display of the navigation device isoverlaid with a feedback request 346 that includes a textual messageindicating the nature of the problem with the map data at this location(in this instance, the fact that the street name is unknown), and threevirtual buttons 348 350 and 352 marked “YES”, “LATER” and “DECLINE”respectively. The display of this request may also be announced to theuser using audio, for example by replaying audio corresponding to thetextual message included in the request 346.

If the user should touch the screen in the vicinity of the “YES” button,the navigation device generates a display such as that shown in FIG. 23requesting the user, in this instance, to say the name of the road afteran audio tone has been played. The display shown in FIG. 23 may, asbefore, be accompanied by a corresponding audio message to the user ofthe device, and a short while after the user has been notified thenavigation device generates an audio tone and switches to a record modewhereby input device 204 (which in this instance includes a microphone)is activated and audio received via the input device is recorded to thememory 214 of the navigation device for transfer to the server 150 viathe communications channel 152 when the navigation device is next incontact with the server 150.

In a preferred arrangement user responses are stored along withinformation that allows the server to associate the response with aparticular requested correction. For example, each requested correction(or group of individual requests that relate to the same error in themap data) could be assigned a reference number that is stored with theuser response in the memory 214. In another arrangement, the locationassociated with the user request could be stored with the user response,and other equally plausible arrangements will be immediately apparent topersons of ordinary skill in the art.

If the user should touch the screen in the vicinity of the “LATER”button 350, the user request is cleared from the display and theprocessor records an instruction to seek assistance from the user at alater point in time. In an envisaged implementation, a message similarto that shown in FIG. 20 could be displayed, and the user then promptedto provide assistance when they next select the map corrections optionshown in FIG. 9.

If the user should touch the screen in the vicinity of the “DECLINE”button 352, the user request is cleared from the display and theprocessor records that the user has declined to assist with thisparticular user request. The processor may then be configured to deletethe request, or to notify the server 150 when the navigation device isnext connected that the user has declined this particular user request.The server could be configured to maintain a log of declined requestsand in the event that more than a given number of requests are declinedby the user of a particular device, to issue instructions for transferto the user of that device to cause the processor to indicate to theuser of the device that they have declined requests for assistance onmultiple occasions in the past, and provide the user with the option toremove their device from the list of devices that the server canapproach for assistance with map data corrections.

In another envisaged implementation the user request generated by theprocessor could provide the user with the option to provide a textualresponse, or indeed a mix of textual and audio responses.

Referring again to FIG. 21, the server may be configured simply toreceive and store user responses for later consideration by a humanoperator, in particular for consideration whether at least a proportionof the responses are sufficiently similar to merit correction of the mapdata.

Optionally, however, the server may be configured to employ a responsereview module 342 that is operable to review received responses todetermine whether at least a predetermined proportion of those responsesinclude the same or similar user response. In one envisagedimplementation the response review module may be configured to reviewreceived responses only when responses have been received from apredetermined proportion of the devices to which user requests weretransmitted, and to indicate that a particular response is valid when atleast a predetermined proportion of received responses are identical orat least similar. In another arrangement, the response review module maybe configured to implement a statistical review of responses receivedwhereby each new response is compared to existing responses until astatistically significant number of responses with the same or similarinformation have been received.

For textual responses the response review module 342 may simply beconfigured to compare text of received responses, and to deem a givenresponse to be valid if it is the same or similar to a number of otherresponses. The degree of similarity that must occur for responses to bedeemed to be the same may be automatically adjusted with the type ofcorrection request so that for street names (where typographical errorsmay occur) a lower level of similarity is required than might berequired for speed limits, for example. Once again, such functionalitycan readily be implemented by persons skilled in the art using knowntechniques for statistical analysis.

For audio responses, the response review module 342 may be configured toinvoke speech analysis functionality to convert received audio into acomputer intelligible form before received responses are compared. It isalso recognised that a comparison of the received audio could beundertaken, using conventional audio analysis techniques, but it isanticipated that such an approach may prove less useful given differentaudio qualities of the environments in which the responses are capturedand likely differences between users.

In a particularly preferred arrangement, the response review module mayalso be configured to automatically delete responses relating tocorrections that have already been made to the map data. In this way, aresponse that is late received (for example because the user has notconnected their device to the server 150 for a relatively long period oftime, or has been tardy in inputting the correction) can readily beignored by the server 150.

Once received responses have been validated, for example by the responsereview module aforementioned, the server may optionally invoke acorrection application module 344 that is configured to automaticallyapply a determined correction to the map data stored in the mass storagedevice 160 of the server 150.

As aforementioned in connection with FIG. 5, the navigation deviceprocessor 202 is configured to invoke and execute software modules inmemory 214. In particular, as shown in FIG. 24, the processor 202 andmemory 214 cooperate to support a BIOS (Basic Input/Output System) 280that functions as an interface between functional hardware components ofthe navigation device 200 and software executed by the processor 202.The processor 202 is configured to load an operating system 284 thatprovides a processing environment in which application software 286 canrun.

The application software includes conventional navigation devicesoftware modules such as route planning, navigation, and map renderingmodules the like of which are well known in the art and for brevity willnot be described herein in detail. It suffices to mention that the routeplanning module enables a user of the device to input a start locationand plan a route to an inputted destination, that the navigation moduleenables the device to receive GPS signals, determine the device locationand generate route guidance instructions for provision to the user, andthe map view rendering module is configured to generate displays ofregions of the digital map, for example a region where the device iscurrently located as determined by the navigation module.

The application software also includes a user request module 354 and auser response module 356. In this embodiment the user request module 354is configured to cooperate with the navigation module to invoke, at anappropriate location defined by the user feedback request received fromthe server, instructions included in the user feedback request togenerate an appropriate user feedback request—such as that shown in FIG.22—for display to the user on the display of the navigation device 200.

The user response module 356, in the manner described above inconnection with FIGS. 22 and 23, functions to record that the user doesnot wish to respond at this time and to configure the navigation deviceto prompt the user to respond at a later point in time, to record thatthe user does not wish to respond (and optionally notify the server ofthis in due course) or to record a user response to the displayedrequest in the memory 214 for later upload to the server 150.

In the foregoing embodiment it has been assumed that the device ispredominately operated in a mobile mode without a connection to theserver 150, but it will be apparent to persons skilled in the art thatthe teachings of the present invention could equally well be implementedin a system where the location, or at least the general location, ofeach navigation device is known. For example, the navigation devicecould be configured to periodically transmit its location, as determinedby the navigation module from received GPS signals, to the server 150using, for example, an integral or connected mobile communicationsdevice (such as a mobile telephone or a telephony equipped PDA).

In an alternate arrangement the approximate location of the navigationdevice could be determined by means of conventional triangulationtechniques that enable the approximate location of a mobile telephone tobe calculated based on its communications with mobile transceiverstations of the mobile telephone network.

In either case, the server could be configured to implement apseudo-real time system by sending user requests, for example by meansof a mobile communications device that forms part of or to which thedevice is connect, to a selection of those navigation devices that arecurrently in the vicinity of a location that is associated with areported need for map data correction.

In a particularly preferred implementation for any of the aforementionedembodiments, the navigation devices could be preloaded with form datafor different types of user request, and in such an arrangement the userrequests transmitted by the server (for example in cooperation with amobile telephone network) need only comprise unique data pertaining tothe particular correction being investigated at that time.

Referring now to FIGS. 25 and 26, there are shown in the form of flowdiagrams the various functional steps in the process of flagging mapdata as needing correction, and subsequently enlisting the help of usersin validating a requested correction.

Referring firstly to FIG. 25, in a first step the user switches on theirnavigation device and operates it either as a route guidance tool or ina free-driving mode. If the user should notice an error in the map datawhilst using the device, the user can notify the device of the error,whereupon the device liaises with the user to determine the type oferror noted, the correction required and the location that the error isassociated with records the error as a correction request in the device.

When the device connects with the server, for example when the device isnext coupled to the device via an internet or immediately if the deviceis connected to the server whilst being operated, the device transmitsthe error correction request to the server.

Referring now to FIG. 26, on receipt of a correction request from adevice the server stores the request in the correction request store.The server selects a request for validation by users, selects the set ofdevices that are to be asked to assist with validation of the correctionrequest, and generates a user request for transmission to the selecteduser devices (for example when those devices are next connected to theserver). In due course the generated user requests are transmitted tothe selected devices.

The devices receive the transmitted user requests, and obtain a responsefrom the user in the manner aforementioned. The responses are thentransmitted back to the server for processing.

The server receives the user responses from the navigation devices,analyses the responses received, and determines whether the responsesindicate that the requested correction is valid. If the requestedcorrection is determined to be valid, the map data is amendedaccordingly and the process ceases. If the requested correction is notdetermined to be valid, processing ceases.

It will be appreciated from the foregoing that the teachings of thepresent invention provide a powerful means for validating requestedcorrections to map data in a navigation system. The arrangementsdisclosed avoid much of the expense associated with traditional methodsof validating correction requests, and facilitate a quicker respond tonoted errors. Furthermore, in preferred embodiments of the invention itis significantly harder for nefarious individuals to pollute the mapdata with incorrect submissions.

It will also be appreciated that whilst various aspects and embodimentsof the present invention have heretofore been described, the scope ofthe present invention is not limited to the particular arrangements setout herein and instead extends to encompass all arrangements, andmodifications and alterations thereto, which fall within the scope ofthe appended claims.

For example, although the above embodiments described in the foregoingdetailed description refer to GPS, it should be noted that thenavigation device may utilise any kind of position sensing technology asan alternative to (or indeed in addition to) GPS. For example thenavigation device may utilise using other global navigation satellitesystems such as the European Galileo system. Equally, it is not limitedto satellite based but could readily function using ground based beaconsor any other kind of system that enables the device to determine itsgeographic location.

Alternative embodiments of the invention can be implemented as acomputer program product for use with a computer system, the computerprogram product being, for example, a series of computer instructionsstored on a tangible data recording medium, such as a diskette, CD-ROM,ROM, or fixed disk, or embodied in a computer data signal, the signalbeing transmitted over a tangible medium or a wireless medium, forexample, microwave or infrared. The series of computer instructions canconstitute all or part of the functionality described above, and canalso be stored in any memory device, volatile or non-volatile, such assemiconductor, magnetic, optical or other memory device.

In addition to the foregoing, whilst the present application hashitherto described the validation of corrections suggested by users, itwill be appreciated that the teachings of the present invention mayequally well be employed in the validation of any proposed map datachanges—not merely those that are mooted in response to a user request.Similarly, whilst the foregoing has described the transmission of userrequests to a plurality of users, it will be appreciated that many ofthe benefits of the present technique could be enjoyed if only a singlerequest were to be transmitted to a single navigation device.

It will also be well understood by persons of ordinary skill in the artthat whilst the preferred embodiment implements certain functionality bymeans of software, that functionality could equally be implementedsolely in hardware (for example by means of one or more ASICs(application specific integrated circuit)) or indeed by a mix ofhardware and software. As such, the scope of the present inventionshould not be interpreted as being limited only to being implemented insoftware.

Lastly, it should also be noted that whilst the accompanying claims setout particular combinations of features described herein, the scope ofthe present invention is not limited to the particular combinationshereafter claimed, but instead extends to encompass any combination offeatures or embodiments herein disclosed irrespective of whether or notthat particular combination has been specifically enumerated in theaccompanying claims at this time.

1. A system for use in the validation of a correction to map data for ageographic location, the system comprising: a processing resource; and anavigation device; wherein the processing resource comprises: a userrequest generator that is configured to generate a user request fortransmission to the navigation device; a transmitter for transmittingthe generated user request to the navigation device; and a receiver forreceiving a user response from said navigation device; and wherein thenavigation device comprises: a receiver for receiving the user requesttransmitted from the processing resource; a user request moduleconfigured to present said received user request to a user of thenavigation device; a user response module for capturing a user responseto said presented user request, and a transmitter for transmitting saidcaptured user response to said processing resource.
 2. A systemaccording to claim 1, wherein the user request includes positioninformation defining one or more geographic locations at which said userrequest module presents said user request to said user.
 3. A systemaccording to claim 2, wherein the navigation device includes anavigation module configured to determine the geographic position of thenavigation device, and said user request module is configured to presentsaid user request to the user when said navigation module indicates thatthe geographic location of said navigation device is included in saidposition information.
 4. A system according to claim 3, wherein saidposition information defines a zone that is a predetermined distancefrom the location associated with said geographic location.
 5. A systemaccording to claim 4, wherein said predetermined distance varies inaccordance with the type of correction that is to be validated.
 6. Asystem according to claim 1, wherein said user request generator isconfigured to generate a plurality of user requests, each fortransmission to a different navigation device.
 7. A system according toclaim 6, wherein said processing resource comprises a device selectionmodule operable to select navigation devices to which generated userrequests are to be transmitted.
 8. A system according to claim 7,wherein said processing resource comprises a route log configured tostore navigation routes travelled by navigation devices.
 9. A systemaccording to claim 7, wherein said device selection module is configuredto select a set of devices for which a route is stored in said route logthat includes a location in the vicinity of the geographic locationassociated with said correction.
 10. A system according to claim 9,wherein said device selection module is configured to select a set ofdevices for which a route is stored in said route log that includes thegeographic location associated with said correction.
 11. A systemaccording to claim 9, wherein said device selection module is configuredto randomly select a set of devices from a plurality of devices for eachof which a route is stored in said route log that includes a location inthe vicinity of the geographic location associated with said correction.12. A system according to claim 1, wherein the processing resourcecomprises a response review module for analysing user responses tovalidate said correction.
 13. A system according to claim 1, whereinsaid user request module is configured to present said user request byplaying an audio message to said user.
 14. A system according to claim1, wherein said user request module is configured to present said userrequest by displaying a visual message to said user.
 15. A method foruse in the validation of a correction to map data for a geographiclocation, the method comprising: generating a user request fortransmission from a processing resource to a navigation device,transmitting the generated user request to the navigation device;controlling the navigation device to present the user request to a userof the navigation device; capturing a user response to said presenteduser request; and transmitting the user response to said processingresource.
 16. A method according to claim 15, further comprisinganalysing said user response to validate said correction.
 17. (canceled)18. A method for use in the validation of a correction to map data for ageographic location, the method comprising: receiving, at a navigationdevice, a user request transmitted from a processing resource;controlling the navigation device to present the user request to a userof the device; capturing a user response to said presented request; andtransmitting said user response to said processing resource.
 19. Acomputer program embodied on a computer readable medium comprising oneor more computer program modules configured, when executed by aprocessing resource, to cause the processing resource to implement amethod as defined in claim
 15. 20. A computer program embodied on acomputer readable medium comprising one or more computer program modulesconfigured, when executed by a processing resource, to cause theprocessing resource to implement a method as defined in claim
 18. 21.(canceled)
 22. A navigation device (200) configured for use in a systemfor use in the validation of a correction to map data for a geographiclocation, the navigation device comprising: a receiver for receiving theuser request transmitted from a processing resource; a user requestmodule configured to present said received user request to a user of thenavigation device; a user response module for capturing the userresponse to said presented user request; and a transmitter fortransmitting said captured user response to said processing resource.